センドメール株式会社 (Sendmail, K.K.)
末政 延浩
2011年7月
1. 概要
2. 公開鍵の提供
3. 鍵の管理
4. 送信側での署名
5. 正規化処理
6. 受信側での処理
7. 認証結果の扱い
8. DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
9. 認証結果のヘッダへの表示
1. 概要
Domainkeys Identified Mail (DKIM) は、電子署名方式の送信ドメイン認証である。IETFにおいてSendmail社のEric Allman氏らを中心として検討が進められ、RFC 4871およびRFC 5672として標準化された。さらに、DKIMの規格を補うDKIM-ADSPという標準があり、RFC 5617で標準化されている。
図1に示すように、DKIMでは送信側で電子メールに電子署名を付加し、受信側でその電子署名を照合するという方法で送信者のドメインの認証を行う。メッセージのヘッダや本文を元に電子署名を作成するため、中継MTAなどで電子署名または電子署名の元になった電子メールのデータが変更されなければ、たとえメールが転送されたとしても転送先において認証が可能になる。
図1 DKIMによる送信ドメイン認証
2. 公開鍵の提供
DKIMでは、送信側のドメインを管理する権威DNSサーバーを使用して、署名に利用する公開鍵を公開する。公開鍵は、次に示すFQDN（Fully Qualified Domain Name：完全修飾ドメイン名）に対するTXTレコードとしてDNSに登録する。鍵の長さは、512ビットから2048ビットをサポートしている。RFCでは2048ビットより大きな鍵を利用する場合もあるとされているが、実際にはDNSプロトコルの512バイトにうまく収まる最も長い鍵として2048ビットまでが現実的であると説明されている。また、1024ビットより短い鍵では、オフラインでの解読行為に対して脆弱である場合がある。
DKIMでは広範な普及を目指すため、鍵作成のコストを抑え、より多くのサイトにて利用できるように考慮している。DKIMでの電子署名では、第三者認証局が発行した電子証明書を利用するのではなく、OpenSSLなどのツールを使って各ドメインの担当者らが、自身が管理するドメインの鍵を自身で作成する。また、たとえばOpenDKIMでは、opendkim-genkeyというツールが提供されており、DKIMの署名に必要な秘密鍵と公開鍵を作成できる。作成した公開鍵を登録するFQDNの形式を次に示す。
<セレクタ>._domainkey.<ドメイン名>
ここで<セレクタ>とは、DKIM-Signatureヘッダのsタグに指定したラベルになる。また、<ドメイン名>は、同じくdタグに指定されたドメイン名である。異なるセレクタを用意することで、同じドメインに対して複数の公開鍵を運用できる。公開鍵のレコードは、「タグ＝値」を“;”で列挙する。レコードの例を次に示す。また、利用できるタグを表1に示す。
sls.dkim._domainkey.smtest.com. 300 IN TXT "v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3...<省略>"
表1 利用できるタグ
| タグ | 値 | 説明 | 省略 |
| v | Keyレコードのバージョン番号 | 指定する場合は「DKIM1」になる。省略時も「DKIM1」である。指定する場合は、レコードの最初に記述する | 設定することが推奨されるが、省略可能 |
| g | 鍵の適用条件パターン | 電子署名の対象とするメールアドレスのローカルパートにマッチする条件パターン。ワイルドカード文字“*”が利用できる。この鍵を利用できる送信者のアドレスを限定する場合に利用する。省略時は「*」になる | 省略可能 |
| h | 利用可能なハッシュ方式 | 電子署名の作成の際に利用できるハッシュの方式を限定する。省略した場合、すべてのハッシュ方式を許容する。DKIMでは現在、SHA1とSHA256のみサポートしている。署名作成者と照合者の両方が、SHA256方式をサポートする必要がある。また、照合者は、SHA1もサポートする必要がある | 省略可能 |
| k | 鍵の形式 | 電子署名の作成の際に利用できる鍵の形式を指定する。DKIMでは現在、RSA形式のみサポートしており、省略時は「RSA」になる | 省略可能 |
| n | 説明 | 可読な説明文を保持するタグ。省略時は無し（長さゼロ（0）の文字列） | 省略可能 |
| p | 公開鍵データ | 公開鍵のデータを保持するタグ。鍵データはBase64でエンコードする。また、値が指定されない場合は、該当の鍵が無効になっていることを示す | 必須 |
| s | サービスタイプ | 当該鍵が有効であるサービスを指定する。カンマで区切って複数指定できる。現時点で指定できるサービスは「*」（すべてのサービス）と「email」（電子メール）の2つがある。省略時は「*」となる | 省略可能 |
| t | フラグ | フラグを指定する。コロン“:”で区切り、複数指定することができる。指定できるフラグには「y」と「s」がある。「y」は、DKIMの運用が試験モードであることを示す。yフラグがある場合、受信者は認証に成功したメールとそうでないメールを区別して処理してはいけない。「s」が指定されている場合、iタグに指定されたアドレスの@（アットマーク）から右のドメイン名はdタグに指定された値と一致する必要がある。省略時はフラグ無し | 省略可能 |
3. 鍵の管理
言うまでもなく、署名に利用する秘密鍵の管理は十分な注意を払い、本当に必要な人以外のアクセスをできなくする必要がある。暗号化方式の脆弱性や万が一の秘密鍵の漏洩などに備えて、鍵は定期的に更新することが勧められる。公開鍵の更新のときには、新しいセレクタを作成し、公開中のFQDNとは異なるFQDNで新しい公開鍵を公開できる。いままで利用していた公開鍵と新たに利用開始する公開鍵を並行して公開する。古い公開鍵については、適当な期間が経過したのち、公開鍵の値を削除することで鍵の無効化を宣言できる。配送経路において電子メールがキューされている可能性のある期間を考えると、該当の公開鍵で署名しなくなったあとも、特別な理由がない限り最短で10日程度は並行に公開しておく。
4. 送信側での署名
送信側では、電子メールのヘッダおよびボディを元に電子署名を作成し、作成した電子署名をDKIM-Signatureヘッダとして追加する。DKIM-Signatureヘッダの書式は、“タグ＝値”の組を“;”で区切って列挙する。DKIM-Signatureヘッダの例を次に示す。また、タグの一覧を表2に示す。
図2 DKIM-Signature:ヘッダの例
表2 タグの一覧
| タグ | 値 | 説明 | 省略 |
| v | バージョン | バージョン番号を示す。現時点では、このタグには1と指定する | 必須 |
| a | 署名の作成に利用したアルゴリズム | 署名の作成に利用したアルゴリズムを指定する。「rsa-sha1」と「rsa-sha256」が利用できる | 必須 |
| b | 電子署名データ | 電子署名データ。Base64にエンコードして指定する | 必須 |
| bh | 本文のハッシュ値 | 電子署名の対象とした本文のハッシュ値 | 必須 |
| c | メール本文の正規化方式 | 署名作成のときに利用する正規化処理の方法を指定する。“/”で区切り、それぞれヘッダと本文の正規化に利用したアルゴリズムを表示する。「simple」と「relaxedが」指定できる。省略した場合は「simple/simple」になる。詳細については以下の節で述べる | 省略可 |
| d | ドメイン名 | 署名を行ったドメイン名。送信ドメイン名である。公開鍵の取得の際に参照するドメイン名の一部になる。後述のiタグに与えられるアドレスのドメイン名は、このタグに与えられる値と同じか、またはサブドメインである必要がある | 必須 |
| h | 署名したヘッダ | 電子署名を作成するデータに含まれたヘッダ。“:”で区切って複数列挙できる。送信者を示すヘッダ「From:」や「Sender:」などは必ず署名対象に含める必要がある | 必須 |
| i | 認証対象送信者アドレス | メールの送信者や送信プログラム（メーリングリストなどの場合）のメールアドレス。省略した場合は、dタグに指定したドメイン名の先頭に@を追加した値になる | 省略可 |
| l | 署名対象本文長さ | 電子署名を行ったメール本文の先頭からの文字長（バイト長）。省略した場合、本文全てを署名対象とする。署名実施するシステムの処理能力とのトレードオフであるが、一般的にあまり小さな値は推奨されない | 省略可 |
| q | 公開鍵取得方法 | 公開鍵を取得する方法を指定する。現時点では「dns/txt」のみ指定可能。省略時は「dns/txt」 | 省略可 |
| s | セレクタ | 公開鍵を取得する際、クエリを発行する対象のドメイン名の一部に利用する。複数のセレクタを持つことで、1つのドメインで複数の公開鍵を利用できる | 必須 |
| t | 署名実施時のタイムスタンプ | 電子署名を作成した日付をEPOC（1970年からの秒数）で指定する。省略時は未定義となる | 利用推奨（省略可） |
| x | 有効期限 | 電子署名の有効期限を指定する。有効である日時をEPOC（1970年からの秒数）で指定する。省略した場合、署名は無期限になる | 利用推奨（省略可） |
| z | 認証対象としたヘッダのコピー | 動作のテスト目的で付与される。実際の認証処理には利用しない | 省略可 |
具体的な処理は以下の通り。送信側は、次の手順で署名を行い、DKIM-Signatureヘッダをメッセージに追加する。
- 署名対象のメールか確認する
- 署名対象のヘッダを決定し、hタグに列挙する
- メールの本文のlタグに指定した長さを取り出し、正規化処理を実施する
- ヘッダ、正規化したメール、これから追加するDKIM-Signatureヘッダの署名データを除いた部分をつなげたデータに対してハッシュを作成する
- ハッシュに対して電子署名を作成し、DKIM-Signatureヘッダに追加したのち、DKIM-Signature自体をヘッダに追加する。
5. 正規化処理
電子メールを配送するとき、中継するMTA、各種セキュリティフィルタ、受信メールサーバなどにおいて、メールのデータが変更されることは多い。変更された場合、DKIMの電子署名が認証不能になる場合もある。配送過程におけるデータの変更をある程度許容できるようにするため、DKIMではメールに署名を付加するとき、対象であるメールのヘッダと本文をあらかじめ正規化処理して得られたデータを元に署名を計算する。受信側の認証処理においても同様の正規化処理をして得たデータを元に認証処理を実施する。DKIMでは、送信者のポリシーに合わせて2つの正規化処理アルゴリズムを利用できる。また、ヘッダと本文それぞれに異なる正規化処理アルゴリズムを適用することも可能である。
simple
この正規化処理アルゴリズムでは、最小限の変更のみが許される。配送途中でのメールデータの変更をあまり許したくない場合に利用する。たとえば、ヘッダに適用した場合は、ヘッダ名の大文字、小文字が変化した場合やヘッダの値に余分な空白が追加された場合でも認証は失敗する。
relaxed
simpleに比べ、配送途中での変更をより許容できる正規化である。送信ドメインの認証処理を最優先に考え、データの変化をある程度（とはいえ、本文の行内に空白が追加されたり、ヘッダ名の大文字・小文字が変化する程度）許容する場合に向いている。
6. 受信側での処理
受信側では、メッセージに付与されたDKIM-Signatureヘッダを取り出し、次の手順で署名の照合を行う。
- DKIM-Signatureヘッダのdタグ、sタグの値から、公開鍵を取得するFQDNを作成する
- 鍵を取得する。このとき、iタグに設定してあるメールアドレスのローカルパートがgタグの条件パターンに合わない場合には、署名の照合を行わない
- hタグに記述してあるヘッダと、メール本文（lタグで有効な本文の長さが指定してある場合には、先頭からその長さだけ切り出したもの）、および電子署名データ以外のDKIM-Signatureヘッダの値を併せてハッシュを作成し、電子署名を作成する
- 公開鍵を利用して、電子署名からハッシュを取り出す
- 電子署名から取り出したハッシュと、受信したメールから作成したハッシュを比較して同じであれば認証成功
7. 認証結果の扱い
DKIMでは、認証する対象の送信ドメインはメールのFromヘッダから取り出すのではなく、あくまでも、DKIM-Signatureというヘッダに指定されているドメイン名や送信アドレスを対象に認証する。つまり、ヘッダ上の送信者であるFrom行の値と公開鍵の取り出しに利用したドメイン名が異なる場合が存在する。DKIMのRFC 4871では認証結果に対するメールの扱いについてははっきりと定義されておらず、DKIM-ADSPのRFC 5617において説明されている。
8. DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
概要
Author Domain Signing Practice（ADSP）とは、DKIMの認証結果をどのように扱うべきかを示すポリシーを送信側で公開するものである。前節で説明したように、DKIMではメールのDKIM-Signatureヘッダから認証対象のドメインを取り出すので、Fromヘッダに指定されている送信者アドレスのドメインと、署名したドメインが異なる場合がある。まず、DKIM-ADSPでは、これを次のように整理している。
| 認証成功した署名 | Valid Signature | DKIMの電子署名の認証処理に成功した署名（DKIM-Signatureヘッダ） |
| メール作成者アドレス | Author Address | メールのFromヘッダに指定されている送信者アドレス |
| メール作成者ドメイン | Author Domain | メール作成者アドレスのドメイン部分 |
| メール作成者ドメイン署名 | Author Domain Signature | 照合が成功した署名で、かつ、DKIM-Signatureヘッダのdタグに指定したドメインとメール作成者ドメインが同一である署名 |
メール作成者ドメイン署名であれば、そのメールの送信ドメインは認証されたと判断される。ADSPレコードの内容が重要になるケースとしては、認証成功した署名がないメール、認証照合した署名のドメイン（dタグで指定）がメール作成者署名と異なる場合などである。
ADSPレコードの公開
ADSPも、送信側のドメインを管理する権威DNSサーバーを使用してTXTレコードで公開する。公開に利用するFQDNは
_adsp._domainkey.<ドメイン名>
となる。<ドメイン名>は、同じくFromヘッダのアドレスのドメイン名部分である。電子署名の認証に使う公開鍵をDKIM-Signatureヘッダのdタグやiタグを元に読み出すの対して、ADSPはFromヘッダ上の送信ドメインから取り出す点には注意が必要だ。ADSPは、“dkim=値”で記述する。値には、次のものがある。
| all | このドメインから送信されるメールは、すべてメール作成者署名が与えられる |
| unknown | このドメインから送信されるメールのいくつか、またはすべてに、メール作成者署名が得られる |
| discardable | このドメインから送信されるメールは、すべてメール作成者署名が与えられる。そして、もしメール作成者署名が得られない場合は、受信者はそのメールを破棄することが望まれる |
＊なお、discardableやallを公開すると、署名して送信したメールが配送経路において再署名されるケース（メーリングリストへの投稿等）や、第三者にメールの送信を委託する場合などにおいて、受信側に厳しい対応をとられる可能性が考えられる。そのような状況を考慮する必要のあるメールを送信する場合、discardableやallの公開については十分に注意が必要である。
9. 認証結果のヘッダへの表示
送信ドメイン認証の認証結果を該当のメールにヘッダに記録する場合の方法は、RFC 5451に標準化されている。RFC5451では、認証結果を記録するヘッダとしてAuthentication-Resultsヘッダを利用するよう定義している。
リスト1 Authentication-Resultsヘッダの例
Authentication-Results: dkim.example.com; dkim=pass (1024-bit key) header.i=user@example.com; dkim-asp=none
このヘッダには、複数の認証処理の結果を記録できる。上記の例では、dkimとdkim-adspの結果が表示されている。Authentication-Resultsヘッダで表示される認証の種類を次の表3に示す。
表3 Authentication-Resultsヘッダで表示される認証の種類
| 認証方式 | 説明 |
| iprev | RFC 5451にて定義されている接続ホストのIPアドレスの逆引きに基づく認証方法 |
| auth | SMTP認証 (SMTP AUTH) |
| dkim | DKIM送信ドメイン認証 |
| dkim-adsp | DKIM-ADSP送信ドメイン認証 |
| domainkeys | DomainKeys送信ドメイン認証 |
| sender-id | Sender ID送信ドメイン認証 |
| spf | SPF送信ドメイン認証 |
各認証方法ごとに、その結果を表示できる。
Authentication-Results: 認証実施したFQDN; 認証結果情報; 認証結果情報; ……
1つのAuthentication-Resultsヘッダで、複数の種類の認証方式による認証結果を表示できる。1つの認証方式による認証結果情報を、次の形で記録する。
認証結果 理由 プロパティ情報
＊「理由」は省略可能
＊「プロパティ情報」は指定されないか、1つ以上指定される場合がある
認証結果は、認証処理の結果を表示するもので、“認証方式ラベル＝認証結果”の値で表示される。また、プロパティ情報によって認証対象が何であったかを表示することも可能である。その場合、“認証対象タグ＝認証対象”の値で表す。複数の認証方式の結果を表示する場合は、“;”で区切って並べる。認証方式ラベルと認証対象タグとして指定されるものを次の表4に示す。
表4 プロパティ情報一覧
| 認証方式 | 認証対象タグ | 意味 |
| dkim | header.i | DKIM認証において、iタグに指定された送信者を元に認証を行った |
| header.d | DKIM認証において、dタグに指定された送信者を元に認証を行った | |
| dkim-adsp | header.from | DKIM-ADSP認証処理においてFromヘッダを元に認証を行った |
| sender-id | header.ヘッダ名 | Sender IDの認証において、表示されたヘッダ名のヘッダに対して認証を行った |
| spf | smtp.mailfrom | SPF認証においてエンベロープの送信者に対して認証した |
| smtp.helo | SPF認証においてHELOコマンドの引数のホスト名を元に認証した |
RFC 5451では、各認証方式ごとにどのようなラベルで認証結果を表すか定義されている。以下にDKIM-ADSPでの結果表示を表5に示す。
表5 DKIM-ADSPでの結果表示
| 値 | 意味 |
| none | メールがDKIM署名されていない |
| neutral | メールはDKIM署名されていたが、DKIM署名の文法上の誤りなどで、照合処理できなかった |
| pass | メールはDKIM署名されており、署名の照合が成功し認証成功した |
| policy | 認証は成功したがローカルなポリシーによってその認証結果は受け入れられない |
| hardfail | メールはDKIM署名されていたが、署名の照合が失敗し、認証が失敗した |
| temperror | 一時的な問題で認証処理を実行できなかった |
| permerror | 照合に必要なヘッダが存在しない場合など永続的なエラーで認証処理を実行できなかった |